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(54) Method for wide area network service location 



(57) A method for a client to locate a particular serv- 
ice from a service provider on wide area computer net- 
works. The method includes multicasting of an adver- 
tisement from a service provider, which advertisement 



is detected by a Service Broker and in turn multicast into 
the wkle area computer network. A client quenes the 
network when seeking a particular service and receives 
in turn the address of the Broker and a Server to ootain 
the servk:e desired. 
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Description 

Reld of th# Inyqntlon 

The instant invention relates to the general problem 
of sen/ice location in wide area cornputer networks and, 
more particularly, to the specific problem which arises 
when a user wishes to locate some service, such as a 
media bridge, internet telephony gateway, H.323 Gate- 
keeper, unicast to multicast bridge, etc., which has some 
desired characteristics, but whose location (in terms of 
network aodress, domain or geographical location) is 
completely unknown and may be anywhere on the pub- 
lic network. 

Background of the Invention 

Today, there exists a number ot examples of wide 
area services. One is media bridges, whicn are devices 
used for mixing voice or video together for multipoint 
conferences. Another might be a media server which 
contains movies and muttimedia accessible to the user 
for playback. Another example are Internet telephone 
gateways. These devices allow Internet hosts to com- 
municate with standard 'POTS* telephone users by 
translating Internet telephony to traditional telephony. 
Yet another example is a multicast to unk:ast bridge, 
which would allow untcast-only endpoints to receive 
multicast. 

Generally, with cunently existing technology, serv- 
ice location mechanisms need to be involved for every 
call set-up. This makes their locatk)n a tinr« critk^l. and 
potentially network and CPU intensive operation. Fur- 
themrare, relaying internet telephony calls to the PSTN 
results in cost for the gateway provider which must 
somehow be passed on to the remote user. This also 
requires security mechanisms to provide authentifica- 
tion and authenticity in an international environment. 

Prior art systems and devices exist for locating sen/- 
ices. but none work well for wide area network sen/ice 
location. For example, some prior art publications have 
taught the use of DNS records for finding sen/ices in a 
particular domain. See for example A. Gutbranosen. P 
Vixte. '/A DNS RR for Specifying the Location of Sen/ices 
{DNS SRV)', IETF Request for Comments 2052. Octo- 
ber 1996. and fl. Moats. M. Hamilton. R Leach, "Finding 
Stutr. IETF intemeiOraft drafl-ieif-srvloc-discovery- 
02.1XL Work in progress. Prior art puolicalions have also 
addressed the problem of finding fax gateways in a par- 
ticular telephone exchange: see. for example. C. Maia- 
mud. M. Rose. 'Pnncipies of Operation for TPC INT 
Subdomam: General Pnnctples and Policy, IETF Re- 
quest for Comments 1 530. October 1 993. 

The use of DNS requires the client to know the do- 
main name where the server is located, which is gener- 
ally not possible. The Service Local ton Protocol, see for 
example. J Veizades, E. Gunman C Perkins. S Kao- 
ian. Sen/fce Location Protocol'. IETF Request (or Com- 
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ments 21 65. June 1 997. is used tor location of sen/k;es 
in an administrative domain, but does not work for wide 
area networks as it ends up using excessive bandwkSth 
as more servers and clients use it. The Session An- 

s nouncement Protocol (SAP). M. Handtey, "SAP - Ses- 
sion Announcement Protocol", IETF Internet Draft. 
Work in Progress, allows for announcement of services, 
but requires an excessive amount of time for clients to 
learn about them. Web search engines, such as Lycos 

?o and Atta Vista, can also be used for the location of sen/- 
ices. However, such search engines tend to generate 
excessive traffic, and service location control rests in the 
hands of a few, dedicated search facilities. This has lim- 
ited scalability. 

15 It is, therefore, an obiect of the instant inventk)n to 
provide a solution to the service location problem which 
is efficient and scalable both in use ot bandwidth and 
CPU power. 

It is a further object of the instant invention to pro- 
20 vide a protocol architecture which alksws clients in a data 
network to readily locate services in a wide area net- 
work. 

It is another object of the instant invention to provide 
a protocol architecture which scales to an infinite 
2$ number of clients and millions of servers without requir- 
ing excessive bandwklths, while at the same tirr^e being 
fast, simple and flexible. 

Summary of the Invention 

The claimed invention comprises a protocol archi- 
tecture which allows clients connected to a data network 
to kx:ate services in a wide area network such as the 
Internet. The invention scales to an infinite number of 
clients and millwns of sen/ers without requiring exces- 
sive bandwidths and is also fast, simple ano flexible. 

The inventive method includes activating a server 
X to provide a sen/tee A to clients and when activated 
server A broadcasts an advertisement for service A to 
a multicast group G^ . 

Broker Y stores the advertisement for sen/ice A in 
its database and broadcasts the advenisement for sen/- 
ice A to a multicast group Go. which advenisement is 
detected by Directory Agent Z and storeo in Z's aata 
base. 

A client looking to fino a server for service A queries 
Directory Agent Z and receives the address tor Broker 
Y, wr>o then provides to the ciieni the aodress lor server 
X 

The client is then able to contact server X to obtain 
service A. 

Brief Da»criptton oi Drawinge 

This invention is pointed out with particularity in the 
appenced claims. The above and further advantages of 
this invention nr^ay be bener understood oy reternng to 
the fol towing description taken m cor i unction with me 
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accompanying drawings in which: 

FIG. 1 is a diagram of the protcxxl architecture of 
the instant invention altowing clients in a data net- 
work to locate sendees in the wide area network; 
and 

FIG. 2 describes the flow of events which occurs 
when the system protocol architecture is initialized. 

Detailed Description of the Invention 

We fomnalty define the wkle area service location 
problem as follows. A client on a computer network (IP 
based. ATM. etc.) wishes to find a server that provdes 
a service. There are no restrictions on the name space, 
network acdress space, geographical location, or ad- 
ministrative domain where the server may be located. 
Furthermore, the client has no knowledge of the location 
of the server. It has only a definition of specific attributes 
or constraints (e.g., supponed protocols, type of billing 
used, cost) which are desirable or metrics to minimize 
or maximize (e.g.. cost, quality, distance). A protocol is 
needed to allow the client to find the server The require- 
ments for such a protocol are: 

1 . Scalable: The protocol should work for many cli- 
ents and sen/ers, without using excessive network 
bandwidth, and without requiring too much time to 
locate the service. 

2. Allow for costs: Network servers may charge for 
their sen/ices. The protocol should albw a client to 
choose a sen/er based on cost minimizatkDn. 

3. Allow for distance: A client may require a server 
to be close to it, in order to minimize network delays. 
It should be possible to locate a server based on its 
proximity to the client. 

4. Support authentiftcation: A client my want to 
know that a server is really trustworthy. Mecha- 
nisms must exist for authenticating and venfying the 
services provided by a server. 

The inventive architecture for the instant invention 
which fulfills these requirements is shown in FIG. i . The 
various components of the architecture are defined as 
foitows: 

Referring first tc the Servers A-0 shown inFIG. l. 
they advertise using network multicast in order to let cli- 
ents use their sen/ices. To do so. they send messages 
into a multicast group, describing the attributes and cost 
structure of the services they provide. 

For each service, a plurality of multicast addresses 
are defined. These are computeo as a string hasn of the 
service. Service Brokers (shown in PIG. 1) listen to this 
multicast address, in aodition. any Server wisning to ao- 
vertise this service also listens to this address. By lis- 
tening to this address, a Server wishing to aovertise on 
It can keep track of the numoer of other Servers also 
advertising 



When using multicast to distribute information 
about services, some kind of control must be exened to 
limit the frequency of advertisements from a server If 
the frequency were fixed, the total number of packets 

5 sent to the multicast group, and received at each broker 
(defined below), would grow linearly with the number of 
servers advertising. This can lead to congestion and 
poor performance. To deal with this, the frequency of the 
advertisements from a server is set to scale back based 

10 on a simple technique. 

Any server which advertises to a multicast group G 
also joins and listens to the group. It counts the number 
of distinct other servers which send advertisements to 
the group. Let* s say N other servers are heard from. The 
period of advertisements from the sen/er is then set to 
N times some basic perioo Tb. This limits the total 
amount of bandwioth on a multicast group to roughly 
one packet every Tb seconds. This is independent of 
the number of servers advertising. The bandwidth us- 

20 age thus scales well, at the expense of less Irequent 
advertisements. 

Some addrtwnal aspects of this base 'tack-off' al- 
gorithm can also be used: 

2S 1 . The period is always made greater than some 
minimum 

2. The minimum period increases with the age of 
the advertisement. The age is defined as the 
number of times the exact same advertisement has 

^ already been sent. When any parameter of the ad- 
vertisement changes, the age is reset to zero. This 
allows okjer advertisements to be sent less fre- 
quently. 

3. A random factor is added so that the actual period 
3S varies randomly between 1/2 and 3/2 of whatever 

the deterrninistic period, computed above, turns out 
to be. The random factor helos avoid some synch ro- 
nizatk)n pathologies that can occur. 

Lef s say a Server hears N other servers. We define 
a parameter CONFIGJNTERVAL_i2. which is the av- 
erage worst-case interval of 1 kbyte packets to be trans- 
m.itted. summed across all se.o/ers. into the multicast 
group. Each Server wishing to send an advertisement 
^5 of size < will periodtcally sena me aovertisement with a 
period T equal to: 



where 

F(age) <s a function whch starts at some fractional 
power of two. 2'^(-CONFIGjNTEPVAL_14). wnenever 
an adveriisemeni is different Irom the previous. For 
each subsequent advertisement which is not aitfereni 
from the previous. Fiagel doubles, until it nits 1. ano 
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T=fl( V2)max(C0NFIG JNTERVAL.l 3*F(age). 
so N*CONFIGJNTERVAL_12*K/102 4). 
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then rl stays fixed at i . We also define R(l/2) as a ran- 
dom variabfe uniformly distributed between 1/2 and 3/2. 
Fd?«arr^te; say that CONFIG Jf^RVAi:_12 is 64m8. 
ThM'ImQans that the total rate of packets sent into the 
group will be 128 kbps when group sizes are large. If 
there are 1000 servers, each sending 1 kByte packets, 
each one will get to advertise once a minute. When 
group sizes are smaller, the packet rate remains at 1/ 
C0NF1GJNTERVAL,13 (perhaps 32 kbps) during 
steady state. However, when an advertisement chang- 
es, the rate can temporarily increase (but not above 
I29kpbs) to hasten the broadcast of this announce- 
ment 

This mechanism allows for the number of Servers 
to grow without causing an increase in the bandwidth 
used on the multicast address. A similar mechanism is 
used in RTF to provide scalability, (described by J. 
Rosenberg and H. Schulzrinne, in "Timer Reconsfdera- 
{ion For Enhanced RTF Scatabiiiiy, proceedings of the 
IEEE, Infocom '98. The advantage of this approach is 
to solve two of the limitatksns of the prior art. First, Serv- 
ers do not need lo know the actual addresses of Bro- 
kers. This eliminates the need for wide-area multicast 
searches and/or Broker advertisements (used in the 
Service Locatcn Protocol). It also nnakcs the system dy- 
namic. Ae soon as a new Broker is turned on. it can im- 
me^sUefy learn about new seryiceet arKJ this process is 
transparent to the servers providing the service (this is 
not the case for the web search engines, for example). 
It also solves the problems of excessive k)ad on brokers. 
The rate is now finely controlled, oidependent of the 
number of Servers. 

Servers that are not multicast capable, or which do 
not want to subscribe to the servce advertisement mul- 
ticast group for reasons of bandwidth or complexity may 
use Notary to diffuse their servrce advertisements as de- 
schbed'below. 

Turning now to a Service Broker (shown in FIG, 1 ), 
this element of the architecture accepts service re- 
quests and sen/ice type requests from clients. These re- 
quests ask for the location of a Server matching a set of 
cnteria described by the client. The Broker answers with 
service replies and servk;e type replies. A Broker gen- 
erally handles service requests for one or several spe- 
cific services: that is why it is called a Sen/ice Broker. 
This is required in order to scale the disk storage and 
processing requiren^ents for Brokers. It is also desirable 
since different services nnay have different requirements 
for matching client requests. For exantple, the Intemet 
telepftony gateway servce nr«y often require searches 
lor Servers which provide the cheapest cost for calling 
a specific destinatk^. Database searches can be organ- 
ized for this kind of query, but only if the broker knows 
that (t will receive mostly or only these type of servce 
requests. 

Like a Server, the Broker mutticasts service an- 
nouncements If a Broker offers a service location for 
service X. Enen it wilt aovenise itself as an offering serv- 
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ice X-broker. For example, a Broker offering a media 
server broker service may use a URL: 

service: nnediaserver-broker7/nnymachine.nnydo- 
main.com: 800 

Brokers themselves can have various attributes 
which define the broker service they provide. For exam- 
ple, this might be a typical attribute specrfication for an 
Internet telephony gateway broker: 
(NUMBER_GATEWAYS=10CO). 
(AUTHENTICAT10N=STR0NG) 

This would define this telephony gateway broker as 
having a database of around 1000 gateways. The au- 
thentication attribute indk:ates that this broker provides 
strong assurances of the correctness of the gateway at- 
tributes it stores. 

Brokers can be additbnally programmed to imple- 
ment some kind ot policy, local to the administrator of 
the Broker. This polk:y nnay restrict the set ot Servers 
whose advertisements are kept by the particular Broker 
For exarr^le. lets say a major ISP is running a broker 
service for telephony gateways for its customers. The 
ISP may decide that the Broker should reject alt Internet 
telephony gateway service advertisennents from Serv- 
ers run by a competing ISP. As another example, a Bro- 
ker may have limited disk space, and may drop ^er- 
tisements for Servers which it believes are ur^ikely to 
be used by any of tts clients^ based, say; onpad history 
bgs of service requests. It should be possible' for any 
sort of polk:y to be implemented. However, Brokers 
shoukj indicate the policy attributes in their sen/ice ad- 
vertisement. 

The use of Brokers for a particular sen/ice also adds 
more scalability. Requests requiring attribute minimiza- 
tion can be considerably more CPU intensive than sim- 
ple kx5k-ups. As the quenes for a particular sen/ice in- 
crease, and begin to exceed the processing capabilities 
of a Broker, additional Brokers can be added to distrib- 
ute the toad. This load distribution can be implemented 
easfy in the directory agent, to which Brokers are reg- 
istered. The entire process becomes transparent to the 
clients and to the Servers. 

The main limitation to scalability for the Brokers is 
the processing burden to search a large number of 
records. If the number of Servers for a particular service 
begins lo exceed several tens of thousands, the storage 
requirements for them, and the time for even a single 
search of the database for a match, can become exces- 
sive. In this scenario. Brokers always have the option ol 
implementing some kind of policy to restrict the size of 
the database. As faster machines ano bigger disks be- 
come available, these policies can be lifted. Further- 
more, such restrictions open up the possd}itity of nnarket 
competition for broker service. If a Broker is willing to 
buy a big enough disk and fast enough machine to store 
and search every Server, that Broker can attract more 
customers to the broker service. 

The use of Brokers allows a client to find out about 
any particular servce. once (t can find a Broker for that 
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service. How does a dient find a broker for a particutar 
service'? To accomptish this, a Directory Agent (FIG. 1) 
rnay be used. This device is Idee a Broker It listens to a 
particutar multicast address to find out services, and ft 
answers client queries for the services it knows about. 
However, ft knows only about a very specific set of serv- 
ices: Broker services. This devce is contacted first by a 
client lo find out a Broker for a particular service. Gen- 
erally, the client must know about its Directory Agent. It 
can learn this informatkxi by DHCP, nnanual configura- 
tion, or via the servk;e tocatK>n protocol. 

A client (FIG. 1 ). of course, is a system which wants 
10 find the address of a Server which can provide some 
service desired by the client. 

A Directory Agent can also function as a Broker and 
mainiatn a data base listing available services. In this 
instance, the Directory Agent would provide service in- 
formation to a client without involving a Broker. Also, of 
course, it is possible that a Directory Agent could pro- 
vide tnformalion available from a Broker directly to a cli- 
ent without identifying any particular Broker 

The final addition to the inventive architecture is a 
new device which we call a Notary. Its purpose is to less- 
en the burden of authenticatkxi which is placed on Bro- 
kers, or to support non-muttk:ast capable Servers. In- 
stead of registering directly with all the Brokers by mul- 
ttcasttng its advertisement, a Sen/er will instead register 
with a Notary. It is the job of this Notary to provide some 
form of authentication for the servers which it repre- 
sents Once authenticated, the Notary acts as a proxy 
tor those Servers, multicasting the advertisements for 
ihem. The form of the service advertisements is nearly 
idenitcai to that of a Server The exception is that alt the 
authenttcatton information in the message is used to au- 
thenticate the Notary, and is the same for all Servers 
being advertised from this Notary. This lessens the bur- 
den of authentication to that of a single Notary, instead 
of many Sen/ers. 

Due to political or technical problems regarding 
crypiographk: technotogies. a unified strong authentica- 
tion mechanism may not be in place very soon. The use 
of Notaries albws the servers to authenticate them- 
selves to the Notary oy any local or proprietary scheme. 

i.n general, tor servces that involve billing authenti- 
cation 01 ihe Server may not be enough. The user may 
want some assurance about the trustworthiness of me 
remote service operator. Notary services could be pro- 
vided by duthonties of sufTicient influence and reputation 
to be trusted by users. Such authorities may, for exan> 
pie. police misbehaving service providers they repre- 
sent, using non-electronic means (such as auditing fi- 
nanoat records, etc.). This kind of nr>odel already exists: 
credit card companies will absorb the costs of fraudulent 
venoors. and revoke their capacilities ;o use the credit 
care to Charge customers. 

Another requirement is for clients to know, at least 
rougniy how aisiant a Server is it is oesiraole for a ctient 
:o inctuce seme ^ina of distance metric in a service re- 



quest to a Broker. 

To support this. Servers should include, in all sen/- 
ice advertisements, an attribute called INfTIAL.TTL. 
This attribute indicates the value of the TTL (Time to live) 

5 fiekj used in the IP packet containing the advenisement. 
When a Broker hears this advertisement on the multi- 
cast address, it notes the TTL in the IP packet when it 
arnved, and the value of the IN1TIAL_TTL aitnbuie. 
From this, a Broker can ascertain the number of hops 

'0 from the server to itself. Similarly, when clients send a 
service request, they also include the INIT1AL_TTL at- 
tribute in the request. When received at the Broker, this 
allows the Broker to know how distant the client is from 
itself. 

'5 In the servce request, a client may optionally in- 
clude the DISTANCE aanbuie. anc specify any allowa- 
ble value for it. A Broker can compute the attribute for 
each record, on a per client basis, by some kind of com- 
bination of the sen/er-to-broker and ciient-to-broker hop 

20 counts. The advantage of this scheme is thai it does not 
require any sort of additional messages to compute dis- 
tance metrics. 

The flow chart in FIG. 2 describes the fk>w of events 
which occurs when the system is initialized. It should be 

2S noted that since the protocol is executed by independent 
network entities, tk^emporal order of events may vary. 

What has been described is the problem of locatkm 
of services in the wide area Internet. The prcposed.Oflw 
architecture for resolving these drawbacks: multicasting 

30 of registrations, sen/ice specific brokers, distance met- 
rics and hierarchical authentication services via nota- 
ries, solves the problems present in prior art systems. 



1. A method for locating services in a wide area inter- 
net network, compnsmg the steps of 

•iO receiving a communication from a Server X de- 

siring to provide a service A to a client connect- 
ed to the internet. 

periodically multicasting an advertisement for 
service A from Server X to a multicast grouo Gi . 
^5 storing, in a Broker Y's database, the aovenise- 

meni for service A mutiicasi by Server X. 
processing a request from client C to Broker Y 
for d Server providing service A. and 
providing from Broker Y to client C an aodress 
so for Server X to obtan Service A. 

2. A method for locating services in a wide area nter- 
net network in accorcancc with Claim V further in- 
cluding the steps of: 

55 

penodically multicasting from Broker v an aa- 
vertisement for Service 5ervtce-A-3roker :o 
multicast grouo G^. 
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storing, in a Directory Agent Z*s database, the 
advertisenr>ent nnulticast by Broker Y. 
processing a communication from clieni C who 
is seeking a Server for sen/ice A, and relaying 
said communication to Directory Agent Z, ^ 
initiating a database search by Directory Agent 
Z for providers of Service Service-A-Broker 
locating Broker Y in response lo said database 
search, and 

returning an address for Broker Y to client C. 

3. A method for locating services in a wide area inte- 
rnet network in accordance with Claim 2, wherein 
said locating step further includes the steps of: 

IS 

querying Broker Y on behalf of client C. and re- 
turning an address for Sen/er X. provided by 
Broker Y, directly to client C. 

4. A method for kxating sen/ices in a wide area inter- 20 
net network in accordance with Claim 1. further in- 
cluding the steps of: 

registering, with a Notary, an advertisement 
generated by a Sen/er, 

providing, by the Notary, authentication for the 
Servers it represents, and 
muttk:asting, by the Notary, the advertisements 
for the Servers registered with the Notary. 

30 
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FIG. 2 



START: SERVER X IS TURNED ON. IT PROVIDES SERVICE A. (goto ll 

1. SERVER X FORMULATES AN ADVERTISEMENT FOR SERVICE A AND 
MULTICASTS IT INTO MULTICAST GROUP G. FROM THEN ON SERVER 
X MULTICASTS ITS ADVERTISEMENT PERIODICALLY. " (goto' 2) 

2. BROKER Y, WHICH OFFERS BROKER SERVICE FOR SERVICE A HEARS 
SERVER X's ADVERTISEMENT. AND STORES IT IN ITS DATABASE 
(goto 3) 

3. BROKER Y SENDS AN ADVERTISEMENT FOR SERVICE A-BROKER 
ANO MULTICASTS IT INTO A MULTICAST GROUP G2. IT WILL' 
MULTICAST IT'S A-BROKER SERVICE ANNOUNCEMENT PERICDICALI Y 
FROM THEN ON. (goto 4) 

4. DIRECTORY AGENT Z HEARS THE A-BROKER SERVICE 
ANNOUNCEMENT FROM Y. H NOTES THAT Y PROVIDES A-BROKER 
SERVICE. ANO STORES THIS INFORMATION IN ITS DATABASE, iaoto 
5) 

5. CLIENT C WISHES TO FIND A SERVER FOR SERVICE A. (goto 5) 
5. CLIENT C CONTACTS DIRECTORY AGENT Z. AND QltRIES IT FOR 

RECORDS GF BROKERS PROVIDING BROKER SERVICE FOR SERVICE A 
(goto 7) 

7. DIRECTORY AGENT Z CHECKS ITS DATABASE. FINDS A MATCH FOR 
BROKER Y. AND RETURNS Y's ADDRESS TO C (goto 8) 

8. CLIENT C CONTACTS Y, ANO ASKS FOR A SERVER PROVIDING 
SERVICE A. (goto 9) 

9. BROKER Y CHECKS ITS OAIABASE. FINOS A MATCH IN SERVER .Vs 
RECORD, AND RETURNS THE ADDRESS ANO CHARACTERISTICS ON X. 
(goto !0) 

;0. CLIENT C CONTACTS SERVER X FOR SERVICE A. 
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